Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ietf/cip/cip-minutes-90july.txt

Text File | 1993-02-17 | 7.4 KB | 201 lines

CURRENT_MEETING_REPORT_


Reported by Claudio Topolcic/BBN

CIP Minutes

Agenda


   o ST-II specification

      -  Identify remaining issues
      -  Discuss remaining issues
      -  Resolve remaining issues
      -  Assign writing tasks

   o Connection oriented protocol research collaboration
      -  Discuss possible collaboration efforts


The CIP Working Group met during all five Working Group sessions.  Our
primary goal for this meeting was to resolve the remaining open issues
in the ST-II protocol specification; three sessions were dedicated to
this effort.  In the other two sessions we discussed collaborative
experiments on connection-oriented internet protocols.

A draft of the ST-II specification was distributed and discussed at the
previous IETF. Several issues were resolved then and new ones uncovered.
Prior to the current meeting, Charlie Lynn distributed an updated draft
incorporating the results of the previous meeting plus ensuing
teleconferences and email.  We discussed the changes and unresolved
issues as follows:


   o Precedence is a per-connection characteristic, and is negotiated in
     the flowspec.  There is a separate priority on each data packet to
     allow for layered coding schemes within one stream.
   o We agreed that all header and option chunks should have 32-bit
     alignment, including 32-bit entities within chunks, to efficiently
     accommodate machine architectures with that constraint.
   o The REFUSE and REROUTE negative response messages will be combined
     into one and the receiver will use the reason code to determine
     what action is appropriate.
   o If ranges of packet rate and size are offered, agents along
     separate branches of a connection might choose incompatible
     combinations each of which meets the minimum product requirement.
     Intermediate agents must keep track of flowspecs along each branch,
     so resolution can be left to the application.
   o To insure that a CHANGE won't cause the existing connection to
     break, the flowspec ranges must include the existing settings.
   o It is not considered an error if the next hop on a path is out the
     same interface as the previous hop, to allow relay multicasting.

                                   1






   o The current specification does not allow a uniform way on all
     control messages to determine the intended client.  New fields are
     to be added to the control message header to allow this.
   o A mechanism for grouping streams is provided, but their use is not
     yet well enough understood, and will therefore, be left to
     experiment.
   o To make use of IP encapsulation paths between ST agents not
     directly connected, the ST routing table must be extended.
   o The current flowspec definition does not allow specifying a
     variable-rate requirement nor discrete steps in place of a range.
     There are provisions to define new flowspec versions as we learn
     what is needed through experiments.


Writing assignments were also issued for sections of the document that
are incomplete but not controversial.  The draft is to be ready for
submission as an Internet Draft in two weeks, followed by submission as
an RFC after a comment period.  The protocol will have ``Not-Recommended
Experimental'' status while the CIP Group and others conduct
experiments.

Collaboration

On Wednesday, we heard status reports on experimenters' plans.  Allison
Mankin described her work to implement Lixia Zhang's Flow Protocol
algorithms within the framework of the BSD OSI TP2 protocol.  She is now
implementing the virtual clock mechanism in the BSD network drivers.
Allison will test the protocol in the MITRE-DCA Testbed Network; she
invites others to use the testbed, too.

Charlie Lynn described the collaboration of BBN and Washington
University in St.  Louis to develop the ``COIP-kernel'' -- basically a
new protocol family added into the BSD socket interface around which a
variety of connection-oriented protocols could be implemented.  The
kernel is to be done by the end of August, then during September BBN
will develop a set of modules around the kernel to implement ST-II.

Paul McKenney told us about the traffic generators he is developing so
that DARTnet experimenters can conduct repeatable experiments.  They run
in user space and can be synchronized at multiple sites, injecting
packets at the NIT, RAW_IP or transport level.  Measures are defined for
both ``best effort'' and ``resource reservation'' types of protocols.

Finally, we discussed how members of the group might collaborate.
Allison expressed interest in using the COIP-kernel to extend Flow
Protocol testing to the DARTnet Sparcstation environment.  Paul's
traffic generators may also be usable in the network testbed.
Conversely, Paul might be able to incorporate Allison's DEC-bit code
into the stochastic fair queuing algorithm.

Meeting action list


                                   2






Casner              Rewrite sect 2 (& 2.1?)  in about 3 pages (may be ok
                    now).

Everyone            Comment on whether sections 2.3 through 2.7 are
                    complete.

Casner              Update old encapsulation text of sect 3.7.3.

Topolcic            Edit or rewrite section 3.7.5 on Robustness.

Lynn                Edit sect 3.7.6.  on Routing to simply list the
                    things we expect from the routing function, but
                    state that routing is not addressed here.

Topolcic            Edit or rewrite section 3.7.8.  on Groups of Streams
                    to state that groups are a way of associating
                    streams and to just list some possible uses of such
                    associated groups.

Lynn                Produce text for section 3.7.9.  on the Source Route
                    Option.

Lynn                Write a section in 4.3.1, FlowSpec that addresses
                    the Burstiness parameter.

Lynn                Edit the paragraphs in section 4.3.1.  that describe
                    LimitOnCost and LimitOnDelay to specify the units.

Topolcic            Rewrite section 4.3.5.3.  on Group Parameter to
                    simply provide suggestions for the uses of Groups.

Lynn                Expand sect 4.4.14 on use of STATUS command for
                    failure detection.

Everyone            Help find all the constants for inclusion in section
                    4.5, Suggested Protocol Constants, and should
                    suggest values.

Everyone            Help write section 6, Areas Not Addressed, and
                    specifically to help draw up a list.

Everyone            Help identify subsets everywhere.

Schroder            Provide protocol exchange diagrams.

Everyone            Think of good way to simplify protocol
                    demultiplexing; consider origin & target(s) of
                    stream on same host.



Attendees

                                   3







Stephen Casner           [e-mail]
Steve Deering            [e-mail]
Kevin Fall               [e-mail]
Kathleen Huber           [e-mail]
Ajay Kachrani            [e-mail]
Charles Lynn             [e-mail]
Allison Mankin           [e-mail]
Paul McKenney            [e-mail]
K.K. Ramakrishnan        [e-mail]
Zaw-Sing Su              [e-mail]
Claudio Topolcic         [e-mail]
Sijiam Zhang             [e-mail]



                                   4